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BRIDGED PATIEm / PROVIDER CENTRIC METHOD AMD 

SYSTEM 

RELATED APPLICATIOMS 

[0001] The following U.S. patent is hereby incorporated by reference into the subject 
application as if set forth herein in full: (1) U.S. Patent No. 6,463,417, entitled "Method of 
Distributing Health Information". 

FIELD OF THE INVENTION 

[0002] This invention relates to medical record access control systems, and, more 
particularly, medical record access control systems that regulate the access-level granted to 
individual medical service providers. 

BACKGROUND 

[0003] The abihty of a patient to regulate the access that a third party has to the 
patient's medical records has become a hotly-contested topic. Typically, systems that 
provide the patient with the ability to control access to their medical records (e.g., 
patient-centric systems) are often administratively-cumbersome for medical service 
providers. Conversely, systems that are easily administered by medical services providers 
(e.g., provider-centric systems) compromise the ability of a patient to control access to 
their medical records. 

[0004] For patient-centric systems, the patient exclusively controls access to their 
health care records. Since the patient's healthcare records are centralized and stored in a 
single location, any provider that accesses the patient's medical record is going to see a 
complete and current medical record, as all the medical service providers access and 
amend the same record set. 
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[0005] While the patient-centric system is preferred by patients, it is difficult to 
implement, since it is often desirable to provide varying levels of access to different 
medical service providers. Therefore, each medical service provider typically requires a 

I 

unique access key to gain access to each medical record. Accordingly, this system requires 
a considerable amount of administrative overhead for medical service providers, in that a 
medical service provider is required to maintain a unique key for each medical record to 
which they have access. 

[0006] For provider-centric systems, the medical service provider maintains a medical ' 
record for each patient to which he provides service. Since the medical service provider ' 
creates and maintains these medical records, the medical service provider has unfettered 
access to the medical records. Further, as each of the medical records is not reconciled with 
the medical records maintained by other medical service providers for the same patient, 
each medical record represents only a partial record of a patient's medical history. 

SUMMARY OF THE IMVEMTION 

[0007] According to a first implementation, a key organization method includes 
receiving a first access key that grants a patient-defined level of access to a first set of 
medical records, receiving a second access key that grants a patient-defined level of access 
to a second set of medical records, and storing the first and second access keys in a 
centraHzed key repository. 

[0008] One or more of the following features may also be included. The first access 
key may be generated by a first patient, and the first set of medical records may concern the 
first patient. The second access key may be generated by a second patient, and the second 
set of medical records may concern the second patient. A client computer connected to a 
distributed computing network may be used to access the first set of medical records using 
the first access key and/or the second set of medical records using the second access key. 
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The client computer may be a personal computer, and the distributed computing network 
may be the Internet. 

[0009] The first and second medical records may be stored on a centralized medical 
record repository. The centralized medical record repository and the centralized key 
repository may reside on and may be executed by a remote server connected to a 
distributed computing network. The remote server may be a web server, and the 
distributed computing network may be the Internet. 

[0010] The first set of medical records may be a multi -portion medical record and the 
first access key may provide access to one or more portions of the first set of medical 
records. The second set of medical records may be a multi-portion medical record and the 
second access key may provide access to one or more portions of the second set of medical 
records. 

[0011] According to a fiirther implementation, a key distribution method includes: 
transmitting, fi'om a first patient, a first access key that grants a patient-defined level of 
access to a first set of medical records; transmitting, fi'om a second patient, a second access 
key that grants a patient-defined level of access to a second set of medical records; and 
storing the first and second access keys in a centralized key repository. 

[0012] According to a fiirther implementation, a key organization method includes: 
establishing, on a remote server, a centralized key repository and a centralized medical 
record repository; and storing a first set of medical records and a second set of medical 
records on the centralized medical record repository. 

[0013] According to a fiirther implementation, a key organization system includes: a 
server system including a computer processor and associated memory, the server system 
having a centralized key repository and a centralized medical record repository; such that 
the server system is configured to: store a first set of medical records and a second set of 
medical records on the centralized medical record repository; receive a first access key that 
grants a patient-defined level of access to the first set of medical records; receive a second 
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access key that grants a patient-defined level of access to the second set of medical records; 
and store the first access key and the second access key on the centralized key repository. 

[0014] One or more of the following features may also be included. A client system 
may include a computer processor and associated memory, the client system being 
configured to: access the first set of medical records using the first access key; and access 
the second set of medical records using the second access key. The server system and the 
client system may be coupled via a distributed computing network, such as the Internet. 

[0015] According to a fiirther implementation, a computer program product resides on 
a computer readable medium on which a plurality of instructions are stored. When 
executed by the processor, the instructions cause that processor to: receive a first access 
key that grants a patient-defined level of access to a first set of medical records; receive a 
second access key that grants a patient-defined level of access to a second set of medical 
records; and store the first and second access keys in a centralized key repository. 

[0016] According to a further implementation, a computer program product resides on 
a computer readable medium on which a plurality of instructions are stored. When 
executed by the processor, the instructions cause that processor to: transmit, firom a first 
patient, a first access key that grants a patient-defined level of access to a first set of 
medical records; transmit, fi'om a second patient, a second access key that grants a 
patient-defined level of access to a second set of medical records; and store the first and 
second access keys in a centralized key repository. 

[0017] According to a fiirther implementation, a computer program product resides on 
a computer readable medium on which a plurality of instructions are stored. When 
executed by the processor, the instructions cause that processor to: maintain, on a remote 
server, a centralized key repository and a centralized medical record repository; and store a 
first set of medical records and a second set of medical records on the centralized medical 
record repository. 
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[0018] The details of one or more implementations are set forth in the accompanying 
drawings and the description below. Other features and advantages will become apparent 
from the description, the drawings, and the claims. 

BRIEF DEBCRBPTIIOIM OF THE DRAWINGS 

FIG. 1 is a diagrammatic view of key organization system coupled to a distributed 
computing network; 

FIG. 2 is a more-detailed diagrammatic view of the key organization system of FIG. 

1; 

FIG. 3 is a block diagram of a key maintenance module of the key organization 
system of FIG. 1; 

FIG. 4 is a block diagram of a key processing module of the key organization 
system of FIG. 1; 

FIG. 5 is a block diagram of a record processing module of the key organization 
system of FIG. 1; and 

FIG. 6 is a diagrammatic view of a patient selection display screen rendered by the 
key organization system of FIG. 1. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0019] Referring to FIG. 1, there is shown a key organization system 10 that manages 
the various access keys 12, 14, 16possessedby a medical service provider 18. Access keys 
12, 14, 16 are provided to medical service provider 18 by various patients 20, 22, 24. 

[0020] Key organization system 10 typically resides on and is executed by a computer 
26 that is connected to network 28. Computer 26 may be a web server running a network 
operating system, such as Microsoft Window 2000 Server ^, Novell Netware or Redhat 
Linux ^. Typically, computer 26 also executes a web server application, such as Microsoft 
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IIS Novell Webserver or Apache Webserver ^, that allows for HTTP (i.e., HyperText 
Transfer Protocol) access to computer 26 via network 28. 

[0021] The instruction sets and subroutines of key organization system 10, which are 
typically stored on a storage device 30 coupled to computer 26, are executed by one or 
more processors (not shown) and one or more memory architectures (not shown) 
incorporated into computer 26. Storage device 30 may be, for example, a hard disk drive, a 
tape drive, an optical drive, a RAID array, a random access memory (RAM), or a read-only 
memory (ROM). 

[0022] As will be explained below in greater detail, a patient (e.g., patient 20) typically 
provides a key (e.g., access key 12) to medical service provider 18 through a patient 
computer 32, which is also connected to network 28. Additionally, medical service 
provider 18 accesses key organization system 10 through a chent computer 34. 

[0023] Referring also to FIG. 2, key organization system 10 includes a centralized key 
repository 50 and a centralized medical records repository 52. Additionally, key 
organization system 10 includes a key maintenance module 54, a key processing module 
56, and a record processing module 58, each of which will be discussed below in greater 
detail. 

[0024] Centralized medical records repository 52 allows for the centralized storage of 
medical records 60, 62, 64 concerning various patients 20, 22, 24 respectively. As 
disclosed in U.S. Patent No. 6,463,417, medical records 60, 62, 64 are typically divided 
into portions or levels, in that certain portions are considered more confidential than other 
portions. For example, a portion / level of the medical record that may be considered the 
least confidential might include general patient identification information and information 
conceming the patient's blood type and allergies. A portion / level of a medical record that 
may be considered to have an intermediate level of confidentiality might include 
information conceming the serological data, psychiatric data, cardiology data, and genetic 
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data. A portion / level of the medical record that may be considered highly confidential 
may include infectious disease (e.g., HIV, and sexually transmitted diseases) data. 

[0025] This specific assignment of confidentiality levels and the apportionment of the 
medical record into various portions / levels is for illustrative purposes only and is not 
intended to limit the scope of this disclosure. 

[0026] Medical records 60, 62, 64 may be incrementally generated / configured 
online by the various medical service providers that provide care to patients 20, 22, 24. 
Altematively, existing medical records may be uploaded (i.e., transferred) to medical 
records repository 52 fi-om a remote storage location (not shown). 

[0027] Referring also to FIG. 3, patients 20, 22, 24 use key maintenance module 54 to 
generate 100 access keys 12, 14, 16 that grant access to various portions of the respective 
medical records 60, 62, 64. Accordingly, though the use of key maintenance module 54, 
the patient can generate access keys that not only regulate who has access to their medical 
records, but also regulates the level of access (i.e., which portions of a patient's medical 
record are viewable by the medical service provider to which the key is provided). 
Examples of access keys 12, 14, 16 are passwords (that allow access to various portions of 
a medical record) and decryption keys (that decrypt various portions of an encrypted 
medical record). 

[0028] Typically, key maintenance module 54 is a web-enabled application that is 
accessed by the patients (e.g., patient 20) through a browser application (e.g., Microsoft 
Intemet Explorer ^, or Netscape Navigator that is running on patient computer 32. 
Altematively, key maintenance module 54 may be a local apphcation that is executed 
locally on patient computer 32. 

[0029] As stated above, key maintenance module 54 allows a patient to generate 100 
an access key for a specific medical service provider that grants, to that medical service 
provider, a defined level of access to that patient's medical records. Once this access key is 
generated, the access key is transmitted 102 to the medical service provider 18. This 
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transmission of the access key may be implemented by transferring the access key from the 
patient to the medical service provider. This may occur by attaching the access key to an 
email that is transmitted to the medical service provider. Once received, the medical 
service provider may then transfer the newly-generated key to the key processing module 
56 (to be discussed below in greater detail) of the key organization system 10. 
Altematively, the patient may directly transfer the newly-generated key to the key 
processing module 54 of the key organization system 10. 

[0030] Now referring to FIGS. 1, 2 and 4, regardless of the manner in which the patient 
transfers the access key to the medical service provider, the access key will ultimately be 
received 120 by key processing module 56, which receives any access keys (e.g., keys 12, 
14, 16) generated and transmitted by patients 20, 22, 24. Once these keys are received 120, 
they are stored 124 on centralized key repository 50. Additionally, if key organization 
system 10 is servicing multiple medical service providers (i.e., at least one medical service 
provider in addition to medical service provider 18), the received keys are associated 122 
with the appropriate medical service provider so that the keys transmitted to a first provider 
are not available to a second provider. 

[003 1 ] Now referring to FIGS. 1 , 2 and 5, when medical records are initially received, 
initially generated, and/or edited, record processing module 58 stores 140 the medical 
record on centralized medical record repository 52. Typically, medical record repository 
52 is a database that allows for the organized storage and retrieval of the medical records 
60, 62, 64. 

[0032] Once these medical records are stored on medical record repository 52, record 
processing module 58 allows the medical service provider 18 to access 142 the medical 
records 60, 62, 64 stored on medical records repository 52. However, the medical service 
provider 18 is only given access to the portions of the medical records for which the 
medical service provider 18 possesses the appropriate key. For example, assume that 
medical service provider 18 is a medical clinic that provides an array of medical services to 
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its patients. Further, assume that patient 20 uses medical service provider 1 8 for all of their 
medical needs; patient 22 uses medical service provider 18 solely for treatment of 
depression; and patient 24 uses medical service provider 18 solely for treatment of HIV. 

[0033] Concerning the access keys generated by each of these patients for medical 
service provider 18: patient 20 would typically provide medical service provider 18 with an 
access key (i.e., key 12) that grants access to their entire medical record; patient 22 would 
typically provide medical service provider 18 with an access key (i.e., key 14) that grants 
access to the general and psychiatric portions of their medical record; and patient 22 would 
typically provide medical service provider 18 with an access key (i.e., key 16) that grants 
access to the general and infectious disease portions of their medical record. 

[0034] Record processing module 58 is typically a web-enabled application that is 
accessed by the medical service provider 18 through a browser application (e.g., Microsoft 
Internet Explorer ^, or Netscape Navigator that is running on client computer 34. 
Typically, medical service provider 18 logs into key organization system 10 using an 
encrypted SSL (i.e., secure sockets layer) connection. 

[0035] Referring also to FIG. 6, when accessing key organization system 10, record 
processing module 58 provides the medical service provider 18 with a rendered screen 
display 158 that includes a list of patient identifiers 160. Patient identifiers 160 define the 
particular patient(s) who provided access keys to medical service provider 18 (i.e., granting 
medical service provider 18 access to various portions of their medical record(s)). The 
patient identifiers 160 may be any element that uniquely identifies the patient, such as the 
patient's name, the patient's social security number, or a unique patient number. In this 
particular example, Mary Jones is patient 20, Timothy Smith is patient 22, and James 
Greco is patient 24. 

[0036] The presence of each of these names in the list of patient identifiers 160 
indicates that a key was received from that patient. In order to access the medical record of 
a patient for which the medical service provider has a key (i.e., for one of the patients listed 
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in the list of patient identifiers 160), the medical service provider 18 selects the appropriate 
identifier using a mouse pointer 162 (or some other pointing device, not shown). For 
example, if the medical service provider wanted to access the medical record of Timothy 
Smith (i.e., patient 22), medical service provider 18 would typically double click (using a 
mouse) on the specific identifier 164 associated with Timothy Smith. Record processing 
module 58 would then, in turn, use access key 14 to access (i.e., retrieve, decrypt, and 
display) medical record 62, the medical record of Timothy Smith, i.e., patient 22. 

[0037] Medical record 62 may be displayed in a separate window or displayed full 
screen on the display of client computer 34. As discussed above, the key provided to the 
medical service provider 18 only allows access to the portion(s) of the patient's medical 
record that the patient wishes to allow access. As discussed above, Timothy Smith (i.e., 
patient 22) is being treated by medical service provider 1 8 for depression and access key 14 
grants access to the general and psychiatric portions of Timothy Smith's medical record, 
such that a link (e.g., link 166) to each available portion is displayed on the right-hand side 
of medical record 64. However, access key 14 does not permit access (i.e., prohibits access) 
to the other portions of Timothy Smith's medical record, namely Allergies, Serological 
Data, Cardiology Data, Genetic Data, and Infectious Disease Data. Accordingly, the links 
(e.g., link 168) to the unavailable data portions are struck-through. 

[0038] Other methods of differentiating the available portions from the unavailable 
portions of a medical record may be used, such as graying-out or not displaying links to the 
unavailable portions. 

[0039] By clicking on the links to the available portions of the medical record, a 
specific available portion is displayed by record processing module 58. 

[0040] While medical record 64 is shown to include a plurality of Unks to the available 
portions of the medical record, other configurations are possible. For example, when 
clicking on a specific identifier (e.g., identifier 164), a medical record may be displayed 
that only includes the portions to which the medical service provider has access. 
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[0041] While centralized key repository 50 is described above as being located on a 
remote server, other configurations are possible. For example, the centralized key 
repository may be stored locally on a computer operated by the medical service provider. 
Additionally, as is known in the art, a repository may be distributed across multiple 
computers / servers. 

[0042] A number of implementations have been described. Nevertheless, it will be 
understood that various modifications may be made. Accordingly, other implementations 
are within the scope of the following claims. 
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